Q. Next.js 프로젝트에서 JWT 쿠키/토큰 관리 관련해 조언을 부탁드립니다!

답변 1

• 

  프로답변러YTN

  코부사장 ∙ 채택률 86%

  ---

  채택된 답변

  멘티님 상황에선 SSR이 401을 만나면 그 자리에서 재발급·쿠키 세팅을 시도하지 말고, 바로 “쿠키를 쓸 수 있는 레이어(예: /api/auth/refresh, server action, middleware)”로 리다이렉트시키고 그 레이어에서만 refresh 토큰으로 재발급 + Set-Cookie 후 원래 페이지로 돌려보내는 흐름을 쓰는 게 가장 현실적인 패턴입니다. SSR에서 fetch로 백엔드를 직접 치지 말고, SSR·클라이언트 모두 Next.js Route Handler(또는 BFF)만 호출하게 한 뒤 이 통로 안에서만 쿠키의 access/refresh 토큰을 읽고, 401이면 백엔드 refresh 엔드포인트 호출 → 성공 시 새 토큰을 쿠키에 세팅하고 원래 요청을 재실행 → 실패 시 로그인 페이지로 리다이렉트하는 식으로 “정상 상태 복원”을 통합하는 것이 많이 쓰입니다. 공통 로직은 보통 두 층으로 나누는데, 서버 공통 로직은 server-only fetch 래퍼나 /api/* Route Handler 안에 두고 거기서만 Authorization 헤더 주입·401 재시도·Set-Cookie를 담당하게 하고, 클라이언트는 axios 인스턴스 하나에 response 인터셉터를 걸어 401 시 /api/auth/refresh를 호출한 뒤 성공하면 원래 요청을 다시 보내도록 해서 “토큰 처리 코드가 퍼지지 않게” 모읍니다. 실무 예제들을 보면 App Router 환경에선 “모든 인증이 필요한 데이터 요청은 반드시 Next.js 서버를 거쳐 외부 백엔드로 나가게 하는 BFF 구조 + 필요하면 middleware로 사전 토큰 검증·리다이렉트” 조합이 가장 흔하고, 이 구조를 쓰면 멘티님이 겪는 ‘SSR은 쿠키를 못 고쳐서 무한 401’ 문제도 자연스럽게 해소됩니다. 채택부탁드리며 파이팅입니다!

  ---
• AD

  

  반도체

  설계팀

  ---

  대기업 반도체 산업으로 취업하기 위해선, 직관적 해석능력과 사고력이 필요합니다. 핵심 역량과 배운 지식을 취업에 활용하고 싶다면 국비지원 강의를 추천합니다.

  확인하러 가기